Brought to you by EarthWeb
IT Library Logo

Click Here!
Click Here!


Search the site:
 
EXPERT SEARCH -----
Programming Languages
Databases
Security
Web Services
Network Services
Middleware
Components
Operating Systems
User Interfaces
Groupware & Collaboration
Content Management
Productivity Applications
Hardware
Fun & Games

EarthWeb Direct EarthWeb Direct Fatbrain Auctions Support Source Answers

EarthWeb sites
Crossnodes
Datamation
Developer.com
DICE
EarthWeb.com
EarthWeb Direct
ERP Hub
Gamelan
GoCertify.com
HTMLGoodies
Intranet Journal
IT Knowledge
IT Library
JavaGoodies
JARS
JavaScripts.com
open source IT
RoadCoders
Y2K Info

Previous Table of Contents Next


3-4
A Frame Relay Primer

EDWARD BURSK

Virtually everyone who makes data communications their business has heard of frame relay. Many people understand, to one degree or another, that frame relay is a form of packet switching. Many have heard that frame relay can save them a lot of money.

Although companies are running their business applications over frame relay networks today, there is still much about this technology that is not well understood. Where did it come from? What is a DLC? What are the potential pitfalls? How can it be used for Internet access? What effect does the emergence of asynchronous transfer mode (ATM) have on frame relay services?

This chapter is devoted to providing answers to these questions. The chapter also offers an update on the current state of public frame relay service (often used for Internet/Intranet access), which has been available commercially for several years now.

HISTORICAL AND PRACTICAL DESCRIPTION OF FRAME RELAY

Packet switching is well-known today, having been introduced into business communications some 20 years ago in various forms—notably as Systems Network Architecture (SNA) from IBM Corp., the X.25 standard of the International Telecommunications Union-Telecommunications Standards Sector (ITU-TSS, formerly known as the CCITT), and ARPANET, which was the progenitor of the Internet. With the widespread deployment of packet-switching devices around the world, this technology—in which streams of data are broken up into discrete blocks of data (called frames or packets) and then statistically multiplexed over a transmission path—is well-proven and considered mainstream.

The form of packet switching called frame relay emerged from a convergence of several factors, including:

  The need for higher-speed packet technology driven by LAN internetworking.
  The availability of a definition for a streamlined packet technique from integrated services digital network (ISDN).
  The desire of equipment vendors and communications carriers to deliver a high-speed packet service as rapidly as possible.

Combined Characteristics of OSI Layer 2 and Layer 3

As a packet-switching technique, frame relay has its roots in X.25 and ISDN standards. ISDN’s D channel—the packet-switching control channel used by ISDN equipment to set up calls—provided a basis for the definition of frame relay. The protocol used over the D channel is called link access protocol for ISDN D channels (LAPD). It is based on link access protocol balanced (LAPB), the protocol used to run X.25 connections over point-to-point links.

LAPB is a link layer, or layer 2, protocol according to the Open Systems Interconnection (OSI) model from the International Standards Organization (ISO). Layer 2 is responsible for establishing and maintaining a reliable connection across a link, guaranteeing that frames of data (as they are called at this level) are successfully transferred across a link without the presence of undetected errors.

X.25 is a layer 3 protocol, wherein network connections (i.e., calls) are made, often traversing many such links. These calls are referred to as virtual circuits, because many can be multiplexed across shared links to many destinations.

Given that it is possible to establish virtual circuits across a frame relay network, many people think of frame relay as a “Layer 2.5” protocol, because it has characteristics of both levels: the ability to establish a point-to-point connection between two devices and the ability to multiplex calls over many links (see Exhibit 3-4-1).


Exhibit 3-4-1.  Multiplexed Virtual Circuits in Frame Relay

Faster Implementation

However, there are some important assumptions made to streamline frame relay’s speed of operation and ease of implementation as compared with other layer 2 and layer 3 protocols such as LAPB and X.25. First, it is assumed that the end devices (i.e., the devices that need to communicate over some distance) are intelligent—that is, they employ a higher-level protocol that guarantees the integrity of the communications between them, negating the need to have the network perform that function itself, as it must with X.25.

Second, it is assumed that the physical and electrical connections (OSI layer 1) are clean—that is, they have a very low error rate, as with the gigabit-speed fiber optic connections used increasingly by long-distance carriers. The result is that few errors occur as a result of using the lines. When errors do occur, frame relay can identify the situation, but does not retransmit the error frame itself. Error frames are simply dropped, with the expectation that the end devices will detect the missing frame and retransmit the data.

A common protocol stack—a grouping of protocols running together, each at different levels of the OSI model—is TCP/IP (Transmission Control Protocol/Internet Protocol). TCP establishes robust transport connections over a network and IP carries data packets across a network. This combination handles retransmission of data if errors occur—a perfect fit for frame relay. Therefore, most of the error-handling and retransmission functions in X.25 and LAPB did not need to be implemented in frame relay, allowing for smaller, faster implementations as compared to X.25.

Exhibit 3-4-2 compares protocol stacks for the OSI model, X.25, and frame relay.


Exhibit 3-4-2.  Comparison of Protocol Stacks


Previous Table of Contents Next

footer nav
Use of this site is subject certain Terms & Conditions.
Copyright (c) 1996-1999 EarthWeb, Inc.. All rights reserved. Reproduction in whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Please read our privacy policy for details.